(レポート) NET308: Amazon Route 53によるDNSデータの統合 #reinvent

(レポート) NET308: Amazon Route 53によるDNSデータの統合 #reinvent

Clock Icon2015.10.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Route 53をプライベートネットワーク向けに利用する

本セッションでは、今までオンプレで管理していたDNSサーバーをAmazon Route53に移行するメリットと方法について解説しています。ふらっと立ち寄った最終日の最終セッションでしたが、不足していた知識を補うことができました。

アジェンダ

screenshot 2015-10-10 12.03.20

全体の流れは、なぜDNSをRoute 53にするのか?から始まり、基本的なDNSのユースケースと、拡張プライベードDNSについて解説しています。

screenshot 2015-10-10 12.07.20

パブリックDNS、プライベースDNS、モニタリングについてそれぞれ考えています。

Route 53への移行

DNSデータをRoute 53に移行する手順として、既存のDNSからのエクスポート、委譲、転送などが考えられます。まるごと移行する場合には、エクスポートしてRoute 53に同じ情報を書き込みます。そして、ドメイン管理事業者が指定するDNSサーバをRoute53に指定することで、パブリックドメインの移管が完了します。

screenshot 2015-10-10 12.15.59

Route 53の優位性

なぜRoute 53に移行するか考えた時、最も大きなモチベーションは、管理不要で、分散配置されていて、安価であることが挙げられます。また、エイリアスの設定、ヘルスチェック、レイテンシーベースのバランシングなど、他には無い機能が多数あります。

screenshot 2015-10-10 12.18.31

ということで、オンプレで行なっていたモニタリングなどの管理は不要となりました。

screenshot 2015-10-10 12.19.40

プライベートDNS

パブリックDNSの管理ができるようになりましたので、続いて、プライベートDNSの管理をしたいと思います。管理コンソールから設定をしましょう。

screenshot 2015-10-10 12.20.27

とても簡単です。以上により、AWS側にほとんどのDNS機能が移管されました。実際にVPC内のインスタンスからプライベートDNS情報が見れるか見てみましょう。以下のようにプライベートなホステッドゾーンを作成して、TXTレコードに「hello world」と書いてみました。

screenshot_2015-10-10_12_50_25

VPC内のEC2から見たTXTの内容です。

screenshot 2015-10-10 12.50.50

確かにTXTレコードが見えましたね。

$ dig txt classmethod.jp

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.39.amzn1 <<>> txt classmethod.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;classmethod.jp.			IN	TXT

;; ANSWER SECTION:
classmethod.jp.		300	IN	TXT	"hello world"

;; Query time: 4 msec
;; SERVER: 172.16.0.2#53(172.16.0.2)
;; WHEN: Sat Oct 10 19:53:12 2015
;; MSG SIZE  rcvd: 56

これでプライベートDNSの移行も完了しました。

screenshot 2015-10-10 12.22.09

拡張プライベートDNS

DNSサーバがクラウド側に来たことによって、オンプレ側にあるPCやサーバからの問い合わせがどのようになるか考えてみましょう。

screenshot 2015-10-10 12.28.33

Amazon DNSサーバー

Amazon DNSサーバーは、VPC作成時に自動で指定されるDNSサーバーです。公式ドキュメントには以下の様な説明があります。

VPC の Amazon EC2 インスタンスにカスタム DNS サーバーを設定した場合は、その VPC 用に Amazon が提供する DNS サーバーの IP アドレスにプライベート DNS クエリをルーティングするように、カスタム DNS サーバーを設定する必要があります。この IP アドレスは、VPC ネットワーク範囲のベースに「プラス 2」した IP アドレスです。たとえば、VPC の CIDR 範囲が 10.0.0.0/16 である場合、DNS サーバーの IP アドレスは 10.0.0.2 です。

例えば、VPCのネットワークアドレスを、「127.16.0.0/16」で作成した場合、カスタムDNSサーバーは「172.16.0.2」です。実際に見てみましょう。確かに「172.0.0.2」が自動的に設定されていますね。

$ cat /etc/resolv.conf 
; generated by /sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 172.16.0.2

VPC の外部にあるカスタム DNS サーバーを使用していて、プライベート DNS を使用する場合は、VPC 内の Amazon EC2 インスタンスのカスタム DNS サーバーを使用するように再設定する必要があります。

さらにVPCの外にあるDNSサーバーとやり取りするためには再設定する必要があると書いてあります。以下の様な場合ですね。

screenshot 2015-10-10 12.44.07

オンプレからクラウドへの問い合わせについては、リゾルバ同士が直接やりとりするのではなく、フォワーダーを経由して通信をします。

screenshot 2015-10-10 12.57.11

フォワーダーには、unboundやActive Directory(SimpleAD)などの製品を置きます。

これにより、オンプレからクラウドへの問い合わせがうまく行きます。

クラウドからクラウドへの問い合わせ

フォワーダーを間に挟むことによて、それぞれのゾーン情報が行き渡るようになりまた。しかし、クラウド側の名前解決がオンプレに向かっていてはもったいないです。

screenshot 2015-10-10 13.18.16

そこで、オンプレのゾーン情報を定期的にクラウド側にコピーすることで、クラウド側の問い合わせがオンプレ側に向かうこと無く、クラウド側だけで完結します。

screenshot 2015-10-10 13.18.30

まとめ

今回は、オンプレからクラウドへのDNS移行と、オンプレとクラウドのDNSの連携について解説しました。ネットワークアドレス+2という制約を回避するために、フォワーダーを用いて連携を実現しているのがポイントですね。皆さんもぜひやってみてください。

参考資料

(NET308) Consolidating DNS Data in the Cloud with Amazon Route 53

Amazon DNS サーバー

プライベートホストゾーンの使用

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.